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(54) An apparatus and method for simulating multiple nodes on a single machine 



(57) The present invention pertains to a system and 
method for simulating multiple clusters of independent 
computer nodes in a single machine. A cluster contains 
one or more computer nodes interconnected by a com- 
munications link. A user can simulate a cluster of n 



nodes by generating n user-level procedures where 
each user-level procedure represents the kernel of a re- 
spective node. An additional mechanism is provided 
which allows a user to exercise the operation of any in- 
tended function in any of the nodes in any of the clusters. 
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Description [0008] The architecture that is simulated includes 

clusters of computer nodes interconnected by a com- 

[0001] The present invention relates generally to the municalions link. Each cluster includes one or more in- 

simulation ot parallel processing systems and particu- dependent computer nodes. Each node is associated 

larly to the simulation of multiple kernel operating sys- s with a number of domains, where each domain repre- 

tems in a cluster processing environment. sents a process having its own address space. One 

such domain is the operating system or kernel that pro- 

BACKGROUND OF THE INVENTION vides a single system image, making the cluster look 

like a single machine to the user, to applications, and to 
[0002] A current trend in the computer industry is the io the network. This single system image allows for user 
Interconnection of a cluster of independent computing or kernel applications to invoke procedures without re- 
nodes connected by a high-speed communications link. gard to where the procedures reside within the cluster. 
Each node is associated with a number of domains, [0009] Each kernel utilizes a number of mechanisms 
where each domain represents a process having its own to achieve the single cluster system Image: a door 
address space. One such domain is the operating sys- is mechanism is used for inter-domain communication; an 
tem or kernel that provides a single system image, mak- object request broker (ORB) is used to process object 
ing the cluster look like a single machine to the user, to invocations; a gateway handler is used to interface with 
applications, and to the network. This single system im- the ORB and the user-level domains; a transport mech- 
age allows user and kemel applications to invoke pro- anism Is used to facilitate communication between the 
cedures without regard to where the procedures reside 20 different nodes; a kernel module library is used to store 
within the cluster. Thus, a user application running in kernel applications; and a cluster membership monitor 
one node can invoke an object whose method is located procedure is used to monitor the operational status of 
in another node of the cluster without requiring the user each node in a cluster. 

application to know the location of the invoked method. [0010] Each node's kemel Is simulated as a user-level 
[0003] Debugging the kernel in a cluster environment 2S procedure A mechanism is provided that allows a user 
presents a numberof challenges. Traditional debugging to configure a simulation environment having a user- 
tools are not suitable since they require that the de- specified numberof simulated nodes that form one clus- 
bugged code be stopped in order to examine data. ter. If needed, multiple clusters can be simulated on the 
When the debugged code is the kernel, the kernel will same machine. In addition, a user has the ability to se- 
be stopped In order to examine kernel data. All process- 30 lect the functions that are simulated and in which node, 
ing in the node ceases when the kernel is stopped. In 

order to avoid this situation, the debugger needs to ex- BRIEF DESCRIPTION OF THE DRAWINGS 
ecute on a separate node. Often, this additional re- 
source is not available. [OQII] Exemplary embodiments of the Invention are 
[0004] In addition, certain kernel procedures can only 35 described hereinafter, by way of example only, with ref- 
execute on one node. In order to debug an n-node clus- erence to the accompanying drawings, in which: 
ter environment, n nodes or computers will be required. 

Often, these additional resources are scarce and not Fig. 1 is a block diagram of a computer system rep- 

readily available. resenting the simulated cluster environment. 

[0005] Accordingly, there needs to be a mechanism 40 

that provides an efficient environment in which the clus- Fig. 2 is a block diagram of a simulation environ- 

ter environment can be simulated for debugging purpos- ment for the computer system shown in Fig 1 
es. 



SUMMARY OF THE INVENTION 

[0006] Particular and preferred aspects of the inven- 
tion are set out in the accompanying independent and 
dependent claims. Features of the dependent claims 
may be combined with those of the independent claims 
as appropriate and in combinations other than those ex- 
plicitly set out in the claims. 

[0007] An embodiment of the invention provides an 
apparatus and method for simulating on a single com- 
puter multiple kernel procedures where each kernel pro- 
cedure represents a node. The kemel procedures are 
simulated as user-level procedures thereby enabling a 
user to debug the kernel procedures. 



Fig. 3 is a block diagram of the computer system 
embodying the simulation environment of the 
present invention. 

Fig. 4 is a flow chart Illustrating the steps used to 
generate the simulated environment and the use of 
the simulated environment. 

DESCRIPTION OF THE PREFERRED EMBODIMENT 

Simulated Cluster Architecture 

[0012] Referring to Fig. 1 , there is shown a computer 
system 100 representing one cluster of computing 
nodes 1 02. A cluster is a set of computing nodes. Each 
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computing node 102 represents an independent com- 
puter that is interconnected via a communications link 
104. It should be noted that the present invention has 
the capability to simulate one or more clusters. For illus- 
tration purposes only, a single cluster is illustrated in Fig. 
1. 

[0013] The communications link 104 generically re- 
fers to any type of wire or wireless link between com- 
puters, such as but not limited to a local area network, 
a wide area network, or a combination of networks. The 
computing nodes 102 use the communications link 104 
to communicate with each other. In one embodiment, 
the communications link can be a System Area Network 
(SAN). 

[001 4] Each node 1 02 has one or more domains 1 26, 
1 28. A domain 1 26, 1 28 is defined to be a process with 
its own address space. A domain 126. 128 can have 
multiple threads of execution (usually called threads) 
that can execute user or kemel application procedures. 
A kernel domain 1 28 refers to the operating system and 
a user domain 1 26 refers to a process other than the 
operating system. 

[0015] In a preferred embodiment, the operating sys- 
tem or kernel 128 is the Solaris MC operating system, 
which is a product of Sun Microsystems, Inc. Back- 
ground information on the Solaris MC operating system 
can be found in "Solaris MC: A Multi-Computer OS," 
Technical Report SMLI TR-95-48. November 1 995, Sun 
Microsystems, which is hereby incorporated by refer- 
ence. 

[0016] A user domain 126 typically executes one or 
more user application procedures 106. A user applica- 
tion procedure 106 can communicate with another pro- 
cedure through a door mechanism 108. Typically, the 
user application procedure 106 can invoke objects with- 
out regard to where the object's method resides. A user 
application procedure 106 in one domain can invoke an 
object where the object's method resides in a different 
domain either in the same node or in a different node 
within the cluster. 

[0017] A door or door mechanism 1 08 is an interproc- 
ess communication (IPC) mechanism that enables pro- 
cedures in different domains to communicate with each 
other. The door mechanism is located in the user do- 
main 126 and in the kemel domain 128. A user applica- 
tion procedure 106 in one domain can issue a call 
through a door 108 that executes code in another do- 
main. In a preferred embodiment, the Solaris door 
mechanism is used which is described in detail in Solaris 
2.6 Reference Manual, distributed by Sun Microsys- 
tems, Inc., 1997 (http://docs.sun.com:80/ab2/@ DSC- 
8rowse?reference=1) which is hereby incorporated by 
reference. However, the present invention is not limited 
to the door mechanism. Other IPC mechanisms can be 
used such as but not limited to sockets, Sun remote pro- 
cedure calls (RPC) and System V IPC. 
[0018]. Briefly, a door 108 describes a procedure in a 
domain 1 26. 1 28 and can contain some associated state- 



information. A domain that obtains a door 108 is free to 
pass it along with its capabilities to another domain in 
the cluster. A server creates a door for some service it 
provides and exports the door 1 08 to clients. Clients who 

5 obtain the door 108 may then invoke the service asso- 
ciated with the door 108 using the synchronous RPC 
semantics of a door call procedure. 
[0019] During a door invocation the client procedure 
that issues the door call procedure migrates to the serv- 

10 er domain associated with the door and executes the 
requested procedure while in the address space of the 
server. When the requested procedure is finished, a 
door return operation is performed and control migrates 
back to the client donnain with the results, if any. from 

IS the procedure call. 

[0020] One task of the kemel domain 128 is to facili- 
tate communication between domains in different nodes 
102. A request to execute a procedure in a different 
node can be received by the kernel 128 from a user or 

20 kernel procedure. The request is converted into a format 
that can be transmitted to the server node containing 
the requisite information needed by the server node to 
execute the requested procedure. N^rious procedures 
in the kernel are used to establish this communication 

25 protocol without any involvement by the requesting user 
or kernel application procedure. The various procedures 
used by the kemel to provide this communication are 
described below. A more detailed description of these 
procedures is found in pending patent application enti- 

30 tied. "A System and Method For Remote Object Invoca- 
tion." serial no. 08/879,150, filed June 19, 1997, and as- 
signed to Sun Microsystems. Inc., which is hereby in- 
corporated by reference. 

[0021] The kernel 1 28 contains an ORB 114 which is 
35 used to process object invocations. In a preferred em- 
bodiment, the ORB 114 utilizes the architecture and the 
specification of the Common Object Request Broker Ar- 
chitecture (CORBRA). A more detailed description of 
CORBRA can be found in The Common Obiect Request 
40 Broker: Architecture and Specification Object Manage- 
ment Group, Inc., Framingham, MA, revision 2.0, July 
1995, which is hereby incorporated by reference. 
[0022] Requests to the ORB 114 can be from user- 
level or kernel-level application procedures. The re- 
45 quests from the user-level application procedures 106 
are transmitted to the ORB 114 through the door mech- 
anism lOStoagateway 112. A gateway or gateway han- 
dler 11 2 is an extension of the door mechanism 108 that 
performs several tasks in order to process object invo- 
ke cations. 

[0023] In some cases, the object invocation is for an 
object's method that resides in a different node. In this 
case, the ORB 114 transforms an object invocation re- 
quest into a logical message that is sent to an appropri- 

55 ate node 102 through a transport procedure 116. The 
transport procedure 116 processes messages to a node 

• identified by a node identifier, determines a network ad- 
dress associated with the node identifier and calls the 
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network interface 11 8 to deliver the message. The trans- 
port procedure 116 can utilize any of the well-known 
"transport layer" communication protocols such as but 
not limited to, transmission control protocol (TCP), user 
datagram protocol (UPD), or the like. Furthermore, the s 
ORB 114 can receive messages from another node 
through the transport procedure 116. 
[0024] A kemel module library 1 1 0 includes a number 
of executable modules that can be dynamically loaded 
upon request. The modules 110 perform kernel-level io 
tasks. The modules 110 include the kernel-level appli- 
cations, as well as other procedures. The kernel appli- 
cation procedures utilize the ORB 114 to process object 
invocations. 

[0025] A cluster membership monitor (CMM) proce- is 
dure 1 20 is provided to detect a node failure. The CMM 
procedures 120 in each node communicate with each 
other at regular intervals to determine the operational 
status of the nodes in the cluster. Communication is per- 
formed at a precise time interval which is initiated by an 20 
interrupt from a software clock procedure 122. The 
CMM procedure 120 informs the ORB 114 when a node 
failure occurs and when a failed node becomes opera- 
tional. 

[0026] One of the nodes 1 02a in each cluster is des- 2S 
ignated a root node since it contains a nameserver pro- 
cedure 1 24. The namesen/er 1 24 is used to identify the 
various objects resident in the cluster The ORB 1 1 4 us- 
es the nameserver 124 to determine the location of the 
object's methods. 30 
[0027] The foregoing has described the cluster envi- 
ronment and infrastructure that will be simulated. Atten- 
tion now turns to the manner in which the cluster envi- 
ronment is simulated. 

35 

Simulation Environment 

[0028] Figs. 2 and 3 illustrate the simulated clusters. 
A single computer 200 can be used to simulate one or 
more clusters of computing nodes. The kernel of each 40 
node represents, In essence, the heart of each node. 
Each kernel is represented as a user-level domain and 
is herein referred to as a simulated kemel domain 216. 
In addition, the computer 200 has a kemel 208, one or 
more user domains 210, and a debugger 230, By rep- 4S 
resenting a node as a user-level domain, the debugger 
230 can be used to debug the simulated kemel domains 
216 without interrupting the operation of the kernel 208. 
In addition, the simulated clusters can be achieved us- 
ing a single computer rather than multiple computers. so 
[0029] The computer 200 can be a workstation, per- 
sonal computer, mainframe or any type of processing 
device. The computer 200 Includes a CPU 202, a user 
interface 204, and a memory 206. The computer 200 
has other system resources which are not shown. The ss 
memory 206 of the computer 200 may be implemented 
as RAM (random access memory) or a combination of 
RAM and non-volatile memory such as magnetic disk 



storage. The memory 206 can include the kemel domain 
208, one or more user domains 210, one or more sim- 
ulated kemel domains 216. a debugger procedure 230, 
as well as other data and procedures. 
[0030] A user domain 210 can include a unode_load 
procedure 212 and a unode_create procedure 21 4. The 
unodejoad procedure 212 is used to execute proce- 
dures in a simulated kernel domain 216. The 
unode_create procedure 214 is used to create one or 
more simulated kernel domains 216. The operation of 
both these procedures will be described below. 
[0031] A simulated kernel domain 216 includes the 
following procedures: a control door or control door pro- 
cedure 218, a transport door or transport door proce- 
dure 220, a simulated gateway or simulated gateway ' 
procedure 222, one or more shared object libraries 224, 
an ORB procedure 114, a CMM procedure 120, a sim- 
ulated clock or simulated clock procedure 226, and a 
simulated transpon or simulated transport procedure 
228. In one particular simulated kernel domain 216, 
there is a nameserver or nameserver procedure 124. 
[0032] A kernel is dependent on the inputs from the 
underlying hardware. As such, not all of the kernel pro- 
cedures can be made to execute as a user-level proce- 
dure. Thus, some of the kernel procedures were re- 
placed by simulated procedures and others required mi- 
nor modifications to make them executable as a user- 
level procedure. The ORB procedure 114, nameserver 
procedure 124, and CMM procedure 120 are basically 
the same procedures that reside in the kernel domain. 
They have been slightly modified in order to become a 
user-level domain by performing syntax changes and 
the like to certain functions internal to these procedures. 
For example, the kernel uses the procedure 
thread_create() with a certain number of arguments to 
create new threads. In the simulated kemel, this same 
function is called thr_create() and takes a different 
number of arguments. 

[0033] A cont rol door 2 1 8 is associated with each sim- 
ulated kemel domain 216 and is used to facilitate com- 
munication to the user domains 210. The control door 
218 is linked to a simulated gateway 222 that accepts a 
command string specifying a particular function to exe- 
cute in the simulated kernel domain 216 and its argu- 
ments. The simulated gateway 222 accepts this com- 
mand string and loads the requested function from the 
shared object library 224. It then converts the com- 
mands into arguments recognizable by the function and 
executes the function with the arguments. The function 
in turn can invoke the methods of one or more objects 
which are processed by the ORB 114. 
[0034] Executable modules in the simulated kemel 
domains 21 6 are represented as shared objects that are 
stored in a shared object library 224. The shared objects 
represent user-level and. kernel-level applications and 
services that are used to simulate the functioning of the 
kernel for debugging purposes. A shared object is char- 
acterized by a module name and a function name. 
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[0035] Communication between the simulated kernel 
domains 216 is achieved through the use of a simulated 
transport procedure 228 and a transport door 220. The 
simulated transport procedure 228 can receive an in- 
struction from the ORB 114 to transmit a message to 
another simulated kernel domain 216. This request can 
be to execute an object's method that resides in another 
simulated kernel domain 21 6 or to perform another task. 
The simulated transport procedure 228 determines the 
transport door 220 associated with the recipient simu- 
lated kernel domain 216. The simulated transport pro- 
cedure 228 then performs a door call to the recipient 
simulated kernel domain 216. This transfers control to 
the intended simulated kernel domain 216 which per- 
forms the requested processing. When the processing 
is completed, a reply is returned to the requesting sim- 
ulated kernel domain 216 by performing a door return 
operation. Control is then transferred to the simulated 
kernel domain 216 of the requesting node which proc- 
esses the response. 

[0036] In addition, the simulated transport procedure 
228 and transport door 220 can be used to transm it clus- 
ter related messages between the simulated kernel do- 
mains 216 of a cluster for other purposes. For example, 
communication between the CMMs of each simulated 
kernel domain 216 within a cluster utilizes the simulated 
transport procedure 228 and transport door 220. This 
communication is achieved through messages that are 
routed via the transport door 200. The simulated trans- 
port procedure 228 is used to convert the messages 
from one format to another fomiat recognizable to an 
intended recipient and to direct the message to an in- 
tended recipient. 

[0037] A simulated clock procedure 226 is provided 
to replace the kernel clock 1 22. The simulated clock pro- 
cedure 226 is used to generate timely clock interrupts 
to the CMM procedure 120 which enables it to monitor 
the status of the simulated kemei domains 21 6 in a clus- 
ter. In one embodiment, the simulated clock procedure 
226 executes as a real time thread in the Sun Solaris 
operating system. 

[0038] A debugger procedure 230 is provided which 
can be used to debug the execution of the simulated 
kernel domains 216. 

[0039] The foregoing has described the mechanisms 
used to simulate the cluster environment. Attention now 
turns to the steps used to simulate the operation of the 
kernels in each node of the clusters. 
[0040] Referring to Fig. 4, inttially, a user generates 
one or more nodes associated with one or more clusters 
(step 300). This is accomplished by calling a 
unode_create procedure 214 which generates a simu- 
lated kernel domain 216 representing a particular node 
in a particular cluster The unode_create procedure 214 
takes a number of arguments such as the name of the 
cluster, an identifier of the node, and the number of 
'nodes in th*e cluster. The unode_create procedure 214 
establishes a control door 218 and a transport door 220 



for the simulated kernel domain and performs other in- 
itialization tasks as well. Once the simulated kernel do- 
mains are created they operate In a like manner as the 
real system kernels and communicate with each other. 

5 [0041] Next, a user domain can execute a particular 
function in a simulated kernel domain (step 302). This 
is accomplished by executing a unodejoad procedure 
212 that exercises a function in a particular simulated 
kemel domain 216. The unodejoad procedure 21 2 can 

70 be embedded in a user application procedure. The 
unode^load procedure 212 specifies that a particular 
simulated kernel domain 216 execute a particular func- 
tion stored in a shared object library 224. The 
unodejoad procedure 21 2 is called from a user domain 

15 21 0 with the following arguments: the name of the clus- 
ter, the node identifier, the name of a module in the 
shared object library 224, a name of a function in the 
module that will be executed, and the function's argu- 
ments. 

20 [0042] The unodejoad procedure 21 2 uses the clus- 
ter name and node identifier to determine the corre- 
sponding control door procedure 218. The unode^load 
procedure 21 2 then invokes a door call using the control 
door procedure 218 which transfers control along with 
25 the arguments to the simulated gateway 222 associated 
with the intended simulated kemel domain 216. The 
unodejoad procedure 212 passes to the simulated 
gateway 222 the name of the module, the name of the 
function in the module, and the function's arguments. 

30 The simulated gateway 222 determines the name of the 
sheared object representing the module and dynamical- 
ly loads in the corresponding shared object if it has not 
already been loaded into memory 206. The simulated 
gateway 222 unpacks the arguments and converts them 

35 into a format that is recognizable by the function which 
is then executed. 

[0043] The function can then execute a number of 
tasks which can involve communicating with other sim- 
ulated kernel domains 216. In this case, the ORB 114 is 
40 utilized which communicates with the other simulated 
kernel domains 21 6 through the simulated transport pro- 
cedure 116 and the transport door 220. 
[0044] When the function completes execution, a re- 
ply is returned to the unode_load procedure 21 2 that re- 
45 quested execution of the function. The reply is transmit- 
ted in one format from the function to the simulated gate- 
way 222. The simulated gateway 222 then converts the 
reply into a format recognizable by the unodejoad pro- 
cedure 212 and executes a door return operation to 
so transmit the reply to the unode_load procedure 212. 
[0045] While the simulated kernel domain 216 Is ex- 
ecuting, a debugger 230 can be used to analyze the ex- 
ecution of the code running in the simulated kemel do- 
main 216 (step 304). Debugging is well known in the art 
55 and the present invention is not limited to any particular 
type of debugging technique. In one embodiment, the 
debugger can execute one or more simulated kernel do- 
mains. The debugger can halt execution of a simulated 
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kernel domain in order to analyze memory locations and 
data values. 

Alternate Embodiments 

[0046] While the present invention has been de- 
scribed with reference to a few specific embodiments, 
the description is illustrative of the invention and is not 
to be construed as limiting the invention. Various modi- 
fications may occur to those skilled in the art without de- 
parting from the scope of the invention. 
[0047] The present Invention Is not limited to the com- 
puter system described in reference to Figs. 1- 3. It may 
be practiced without the specific details and may be im- 
plemented in various configurations, or makes or mod- 
els of distributed computing systems, tightly-coupled 
processors or in various configurations of loosely-cou- 
pled microprocessor systems. 

[0048] Further, the method and system described 
hereinabove is amenable for execution on various types 
of executable mediums other than a memory device 
such as a random access memory. Other types of exe- 
cutable mediums can be used, such as but not limited 
to, a computer readable storage medium which can be 
any memory device, compact disc, or floppy disk. 



Claims 



An apparatus for simulating a cluster of independ- 
ent computer nodes, said apparatus comprising: 

a plurality of user-level domains, each user-lev- 
el domain having a distinct address space and 
having one or more user-level procedures; and 
a plurality of user-level simulated kernel do- 
mains, each user-level simulated kernel do- 
main having a distinct address space and pro- 
viding a capability to simulate a kernel operat- 
ing system, each user-level simulated kernel 
domain including: 
at least one executable procedure; 
a gateway handler procedure receiving a re- 
quest to execute a select one of the executable 
procedures and executing the select executa- 
ble procedure; and 

a first interprocess communication mechanism 
providing communication between a select one 
of the user-level simulated kemel domains and 
the user-level domains; 

wherein the user-level domains utilize the first 
interprocess communication mechanism to re- 
quest execution of a particular one of the exe- 
cutable procedures in a particular user-level 
simulated kemel domain. 

The apparatus of claim 1 , wherein each user- 
level simulated kernel domain includes a plurality of • 
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object methods; 

the apparatus further including an object re- 
quest broker (ORB) that receives a request from the 
select executable procedure to invoke an object 
method. 

3. The apparatus of claim 1 , wherein a subset of 
the user-level simulated kernel domains represent 
a cluster; 

the apparatus further comprising a communi- 
cations membership monitor procedure that moni- 
tors an operational status of each of the user-level 
simulated kernel domains associated with a partic- 
ular cluster 

4. The apparatus of claim 3, further comprising: 

a clock procedure, that at a predefined time in- 
terval, notifies the communicatrans member- 
ship monitor to monitor the operational status 
of each of the user-level simulated kemel do- 
nnains associated with the cluster. 

5. The apparatus of claim 1 , further comprising: 

a debugger mechanism for debugging opera- 
tions of a user-level simulated kernel domain; 
and 

a second interprocess communication mecha- 
nism for handling communications between the 
user-level simulated kernel domains. 

6. A computer-implemented method for simulating a 
cluster of computing nodes, the method comprising 
the steps of: 

providing a plurality of user-level domains, 
each user-level domain including one or more 
user applications; 

providing a plurality of user-level simulated ker- 
nel domains, each user-level simulated kemel 
domain representing a select one of the com- 
puting nodes, each user-level simulated kemel 
domain Including a first interprocess communi- 
cation (IPC) mechanism tor communicating 
with the user-level domains and a particular 
one of the user-level simulated kemel domains, 
a plurality of executable procedures, and an 
gateway handler for executing an executable 
procedure; 

obtaining a request from a specific user-level 
domain to execute an executable procedure in 
a select one of the user-level simulated kernel 
domains; 

determining a first IPC mechanism associated 
with the select user-level simulated kemel do- 
main; 

utilizing the first IPC mechanism associated 
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with the select user-level simulated kernel do- 
main to transmit the request to a gateway han- 
dler associated with the select user-level sim- 
ulated kernel domain; and 
ex cuting the requested executable procedure 
. in the select user-level simulated kernel do- 
main. 

The method of claim 6. said providing step fur- 
ther comprising the steps of : 

generating one or more user-level simulated 
Kernel domains; and ,,,„Hi,or 
associating v^ith each user-level s-mula^ed ker- 
nel domain a cluster identifierand a node iden- 

.imod further comprising the step of pro- 
viding each user-level simulated kernel domain 
with a second IPC mechanism that provides a 
communicaiion path between one or more of 
the user-level simulated kemel domains the 
second IPC mechanism using the cluster iden- 
tifier and the node identifier. 

The method of claim 6. further comprising the steps 
of: 

associatingasubsetoftheuser-levelsimulated 
kernel domains with a particular cluster, and 
providing each user-level kernel domain wrtha 30 
communications membership "^^^J;^"^^ 
mechanism that monitors an operational status 
of each user-level simulated kernel domain as- 
sociated with a particular cluster at predefined 
time intervals. 

, The method of claim 6. wherein the executa- 
IlepToceduresmcludesapluralityofsharedob^cts 

referenced by a module name and a function narne^ 
said executing step further comprising the 

Steps of : 

determining a module name associated with 
the requested executable procedure; 
dynamically loading the module associated 
with the module name into .f ^ 

invoking the function associated with the re- 
quested executable procedure. 

10. The method of claim 6 or 9. further comprising the 
steps of: 

obtaining a reply from the executed procedure; 

transmitting the reply to the requesting user- S5 
level domain. 

11. The method of claim 6 or 9. further comprising the 



Steps of: 



providing an object request broker (ORB) 
mechanism to invoke methods associated wrth 
one or more objects referenced by the request- 
ed executed procedure. 
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